OpenProject 최종 사용자 매뉴얼

2025-09-03, G25DR

1. OpenProject 시작하기

이 장에서는 새로운 사용자가 OpenProject 환경에 접근하고 탐색하는 데 필요한 기본적인 단계를 소개한다. 로그인 방법, 개인 및 프로젝트 수준의 대시보드 이해, 그리고 맞춤형 경험을 위한 개인 설정 구성 방법을 다룬다. 이를 통해 플랫폼을 효과적으로 사용하기 위한 견고한 기반을 제공하는 것을 목표로 한다.

1.1 ‘내 페이지’ 대시보드 활용법

’내 페이지(My page)’는 사용자의 개인화된 대시보드로서, 참여 중인 모든 프로젝트의 중요 정보를 중앙에서 볼 수 있는 공간이다.1 기본적으로 이 페이지에는 사용자에게 할당된 작업 패키지와 사용자가 생성한 작업 패키지 목록이 표시된다. 이는 기능적이지만 수동적인 정보 확인에 가깝다.

’내 페이지’의 핵심 기능은 위젯(widget)을 통한 높은 수준의 사용자 정의 기능에 있다. 사용자는 위젯을 추가, 제거, 크기 조절 및 재배치하여 대시보드를 자신의 업무 흐름에 맞게 완전히 재구성할 수 있다.1 예를 들어, 프로젝트 뉴스, 특정 조건으로 필터링된 작업 목록(예: ‘높은 우선순위의 버그’), 시간 추적 요약 등 다양한 정보를 위젯으로 추가할 수 있다.

사용자의 생산성은 단순히 대시보드를 사용하는 것을 넘어, 대시보드를 자신의 업무 흐름에 맞게 구성하는 노력에 직접적으로 비례한다. 잘 구성된 ’내 페이지’는 여러 프로젝트에 흩어져 있는 중요 정보를 수동으로 찾는 수고를 덜어주고, 사용자에게 핵심 정보를 선제적으로 제공한다. 따라서 ’내 페이지’의 사용자 정의는 선택적인 조정이 아니라, 효율성을 달성하기 위한 핵심적인 단계로 이해해야 한다. 이를 통해 사용자는 자신의 모든 책임을 한눈에 파악하는 중앙 명령 센터를 구축할 수 있다.

1.2 개인 계정 설정

OpenProject는 사용자가 자신의 작업 환경을 최적화할 수 있도록 광범위한 개인 계정 설정을 제공한다. 우측 상단의 사용자 아이콘을 클릭한 후 ’Account settings’를 선택하여 접근할 수 있다.1

주요 설정 항목은 다음과 같다:

• 프로필(Profile): 이름, 이메일 주소 등 개인 정보를 수정한다.1

• 설정(Settings): 언어와 시간대를 설정한다. OpenProject는 30개 이상의 언어를 지원하며, 원하는 언어가 목록에 없다면 시스템 관리자가 활성화해야 한다.1

• 인터페이스(Interface): 다크 모드(Dark mode)나 고대비 모드(High contrast mode)를 선택하여 시각적 편의성을 높일 수 있다. 또한, 작업 패키지의 활동 탭에 표시되는 댓글의 정렬 순서를 변경할 수 있다.1

• 비밀번호 변경(Change password): 현재 비밀번호를 입력하고 새 비밀번호를 설정한다.1

• 2단계 인증(Two-factor authentication): 보안 강화를 위해 모바일 앱 또는 WebAuthn 장치(예: YubiKey)를 사용한 2단계 인증을 설정할 수 있다.1

• 접근 토큰(Access Tokens): 외부 애플리케이션이 OpenProject 리소스에 접근할 수 있도록 API, iCalendar, RSS 토큰을 관리한다.1

• 세션 관리(Sessions management): 현재 활성화된 로그인 세션을 확인하고 더 이상 사용하지 않는 세션을 종료할 수 있다.1

• 알림 설정(Notifications settings): 인앱(in-app) 알림을 받을 조건을 상세하게 설정한다. 예를 들어, 자신이 할당자, 책임자 또는 관찰자로 지정된 작업 패키지에 대한 알림, 마감일이 다가오는 작업에 대한 알림 등을 구성할 수 있다.1

• 이메일 리마인더(Email reminders): 이메일 알림 수신 빈도(즉시, 매일 특정 시간 등)를 설정한다. 이를 통해 정보의 흐름을 관리하고 과도한 알림으로 인한 피로를 방지할 수 있다.1

• 아바타(Avatar): Gravatar 기본 이미지를 사용하거나 개인 프로필 사진을 업로드할 수 있다.1

2. 작업 패키지 관리

이 장은 OpenProject의 가장 기본적인 작업 단위인 ’작업 패키지(Work Package)’에 초점을 맞춘다. 작업 패키지의 생성과 속성 설정부터 협업을 통한 업데이트, 효율적인 목록 관리에 이르기까지 전체 생명주기를 상세히 다룬다.

2.1 작업 패키지란?

작업 패키지는 프로젝트 내에서 추적해야 할 모든 항목을 포괄하는 일반적인 용어다. 예를 들어 과업(Task), 기능(Feature), 버그(Bug), 위험(Risk), 마일스톤(Milestone) 등이 모두 작업 패키지가 될 수 있다.2 이러한 유연성은 OpenProject의 핵심 강점 중 하나로, 하나의 프로젝트 내에서 버그 추적, 기능 개발, 과업 관리 등 다양한 방법론을 동시에 적용할 수 있게 한다.

모든 작업 패키지는 인스턴스 내에서 고유한 ID, 유형(Type), 제목(Subject)을 가지며, 상태(Status), 담당자(Assignee), 우선순위(Priority), 날짜 등 다양한 속성을 포함한다.2 여기서 ’유형’은 관리자가 시스템 설정에서 정의할 수 있으며, 작업을 분류하고 워크플로우를 구성하는 데 중심적인 역할을 한다.2

2.2 작업 패키지 생성 및 편집

작업 패키지를 생성하는 방법은 크게 두 가지다. 첫째, 테이블 뷰(table view)에서 인라인(in-line)으로 생성하는 방식이다. 이는 여러 개의 작업 패키지를 신속하게 만들어야 할 때 유용하다.2 둘째, 분할 화면 뷰(split screen view)를 사용하는 방식이다. 이 방법은 생성 시점부터 설명, 담당자, 마감일 등 상세 정보를 입력하고자 할 때 적합하다.2

생성된 작업 패키지의 속성을 편집하려면, 테이블에서 해당 작업 패키지를 더블 클릭하거나 분할 화면 뷰를 열면 된다. 상태, 우선순위, 담당자 등 대부분의 필드는 클릭 한 번으로 값을 변경할 수 있다.5 날짜 필드를 클릭하면 시작일과 종료일, 기간을 설정할 수 있는 날짜 선택기가 나타나며, 수동 또는 자동 스케줄링 모드를 선택할 수 있다.2

2.3 협업 및 소통

OpenProject는 모든 소통과 자료를 관련 작업 항목에 직접 연결하여 컨텍스트를 중앙에 집중시키는 방식으로 협업을 지원한다. 이는 이메일, 채팅, 파일 서버 등 여러 채널에 흩어져 있던 전통적인 프로젝트 소통 방식의 문제를 해결한다.

작업 패키지 내 ‘활동(Activity)’ 탭에서는 해당 작업에 대한 모든 변경 이력과 대화를 시간 순으로 확인할 수 있다.6 사용자는 이곳에 댓글을 추가하여 팀원들과 논의를 진행할 수 있다. 특정 사용자의 주의를 끌어야 할 경우, @mention 기능을 사용한다. @ 기호 뒤에 사용자 이름을 입력하면 해당 사용자에게 인앱 알림이 전송되어 댓글을 즉시 확인할 수 있게 한다.4 이렇게 남겨진 @mention은 단순한 메시지가 아니라, 해당 과업의 역사에 영구적으로 기록되는 타임스탬프가 찍힌 항목이 된다.

파일 첨부 역시 작업 패키지 내에서 직접 이루어진다. 파일을 드래그 앤 드롭하거나 폴더에서 선택하여 업로드할 수 있으며, 이미지는 설명 필드에 직접 복사하여 붙여넣을 수도 있다.3 이 기능들은 모든 관련 정보와 자료가 작업 패키지라는 단일 진실 공급원(single source of truth)에 모이도록 하여, 의사결정의 맥락을 파악하고 최신 버전의 파일을 찾는 과정을 단순화한다. 이는 프로젝트의 투명성을 높이고 오해를 줄이는 강력한 방법론이다.

2.4 작업 목록 효율적으로 보기

프로젝트가 진행됨에 따라 수백, 수천 개의 작업 패키지가 생성될 수 있다. 기본적으로 제공되는 ‘모든 열린 작업(All open)’ 뷰는 일상적인 업무 관리에 비효율적이다. OpenProject는 이러한 방대한 데이터를 실행 가능한 정보로 변환할 수 있는 강력한 보기 구성 도구를 제공한다.

작업 패키지 테이블 뷰에서 사용자는 필요에 따라 열을 추가하거나 제거하고, 복잡한 필터를 적용하며, 여러 기준으로 정렬하고, 특정 속성(예: 담당자, 상태)에 따라 결과를 그룹화할 수 있다.2 예를 들어, 개발자는 “나에게 할당된 버그를 우선순위별로 그룹화하고 마감일 순으로 정렬“하는 뷰를 만들 수 있다.

이렇게 구성된 뷰는 ‘다른 이름으로 저장(Save as…)’ 기능을 통해 저장하여 나중에 클릭 한 번으로 다시 불러올 수 있다. 이 뷰는 개인적으로 사용하거나 프로젝트 팀원 전체와 공유할 수 있다.2

OpenProject에서 사용자의 개인적인 효율성은 이 보기 구성 도구를 얼마나 잘 활용하는지에 따라 크게 달라진다. 기본 뷰만 사용하는 초보자에서, 여러 개의 목적 기반 뷰를 저장해두고 사용하는 전문가로 발전하는 것이 이 소프트웨어를 효과적으로 사용하는 가장 중요한 성장 과정이다. 따라서 이 기능은 고급 주제가 아닌, 모든 사용자가 숙달해야 할 기본적인 기술로 접근해야 한다.

3. 시각적 프로젝트 관리: 보드와 간트 차트

이 장에서는 애자일과 전통적인 프로젝트 관리 스타일 모두에 맞춰 워크플로우와 타임라인을 시각적으로 관리할 수 있는 도구들을 탐색한다. OpenProject의 핵심적인 설계 철학 중 하나는 작업 패키지 테이블, 애자일 보드, 간트 차트가 분리된 도구가 아니라, 동일한 기본 작업 패키지 데이터를 조작하는 각기 다른 시각적 인터페이스, 즉 ’렌즈’라는 점이다. 한 뷰에서 날짜를 변경하면 다른 뷰의 타임라인 막대 길이가 자동으로 조정되는 것처럼, 시스템이 데이터 일관성을 보장한다. 따라서 사용자는 데이터 불일치에 대한 걱정 없이 현재 작업에 가장 적합한 뷰를 자유롭게 선택하여 사용할 수 있다.

3.1 애자일 보드 활용

보드는 목록(list, 열)과 카드(card, 작업 패키지)로 구성되어 워크플로우를 시각화하는 데 사용된다.8 이는 칸반(Kanban)이나 스크럼(Scrum)과 같은 애자일 방법론을 지원하는 핵심 도구다. 프로젝트 내에서 ‘Boards’ 모듈을 선택하여 기존 보드를 확인하거나 ‘+Board’ 버튼을 클릭하여 새 보드를 생성할 수 있다.8

보드 생성 시, 사용자는 여러 유형 중에서 선택할 수 있으며, 각 유형은 기능과 사용 목적에 따라 뚜렷한 차이를 보인다. 특히 Community 에디션과 Enterprise 에디션 간에 기능적 차이가 존재하므로, 사용자는 자신의 에디션에 맞는 보드 유형을 이해하고 사용해야 한다.

가장 중요한 차이점은 **기본 보드(Basic board)**와 액션 보드(Action boards) 사이에 있다. 기본 보드에서는 카드를 한 목록에서 다른 목록으로 옮기는 것이 순전히 시각적인 재배열에 불과하다. 반면, 액션 보드에서는 카드를 이동하면 해당 작업 패키지의 속성이 자동으로 업데이트된다. 예를 들어, ‘상태(Status)’ 액션 보드에서 카드를 ‘진행 중’ 목록에서 ‘완료’ 목록으로 옮기면, 해당 작업 패키지의 상태가 실제로 ’완료’로 변경된다.8 이러한 차이는 사용자의 혼란을 방지하기 위해 명확히 인지되어야 한다.

다음 표는 OpenProject에서 제공하는 주요 애자일 보드 유형을 비교한 것이다.

보드 내에서 필터 기능을 사용하여 특정 조건에 맞는 카드만 표시할 수도 있다. 예를 들어, “마감일이 2주 이내인 나의 과업“과 같은 필터를 적용하여 칸반 보드를 구성할 수 있다.10

3.2 간트 차트를 이용한 프로젝트 계획

간트 차트(Gantt chart)는 작업 패키지를 타임라인 형태로 보여주는 전통적인 프로젝트 계획 도구다.11 프로젝트 메뉴에서 ‘Gantt charts’ 모듈을 선택하여 접근할 수 있다. 이 뷰에서는 작업의 시작일과 종료일, 기간, 그리고 작업 간의 의존 관계를 시각적으로 파악할 수 있다.12

사용자는 간트 차트 내에서 직접 작업을 생성하고, 타임라인 위에서 막대를 드래그 앤 드롭하여 기간과 일정을 조절할 수 있다.12 두 작업 막대를 연결하여 선행(predecessor) 또는 후속(successor) 관계를 설정할 수 있으며, 이 의존 관계는 파란색 선으로 표시된다.12 후속 작업은 선행 작업이 완료되기 전에 시작할 수 없으며, 선행 작업의 일정이 변경되면 후속 작업의 일정도 자동으로 조정된다.12

마일스톤은 다이아몬드 형태로 표시되어 프로젝트의 주요 기점을 나타낸다.12 또한, 오늘 날짜는 수직의 붉은 점선으로 표시되어 현재 시점을 명확히 보여준다.12

간트 차트 뷰는 확대/축소 기능을 통해 세부적인 일정을 보거나 전체 프로젝트의 윤곽을 조망할 수 있다.12 Enterprise 에디션 사용자는 구성된 간트 차트를 PDF 형식으로 내보내 이해관계자와 공유할 수 있다.12

4. : 문서화 및 회의 관리

이 장에서는 직접적인 과업 관리를 넘어, 지식 공유와 체계적인 소통을 위한 필수적인 협업 기능들을 다룬다. 프로젝트에서 흔히 발생하는 실패 요인 중 하나는 지식의 유실이다. 회의에서 내린 결정이 잊히거나, 프로젝트 문서가 최신화되지 않고 흩어져 저장되는 경우가 많다. OpenProject의 위키와 회의 관리 모듈은 이러한 문제를 해결하기 위해 설계되었으며, 프로젝트의 연속성을 보장하고 지식을 보존하는 역할을 한다.

4.1 위키(Wiki)를 통한 지식 관리

각 프로젝트는 팀원들이 공동으로 문서를 작성하고 관리할 수 있는 위키(Wiki) 공간을 가질 수 있다.14 위키는 프로젝트 문서, 기술 사양, 가이드라인 등 중요한 정보를 기록하고 공유하는 중앙 지식 베이스 역할을 한다.

위키 편집기는 굵게, 기울임꼴, 제목, 목록 등 기본적인 텍스트 서식을 지원하며, 이미지, 표, 링크 삽입이 가능하다.14 특히 강력한 기능 중 하나는 매크로(macro)를 사용하여 동적인 콘텐츠를 삽입하는 것이다. 예를 들어, 특정 필터 조건에 맞는 작업 패키지 목록을 위키 페이지에 삽입하면, 해당 목록은 항상 최신 상태로 자동 업데이트된다.14

위키 페이지는 계층 구조로 구성할 수 있으며, 중요한 페이지는 프로젝트의 주 메뉴에 직접 링크로 추가하여 팀원들이 쉽게 접근할 수 있도록 설정할 수 있다.15 이렇게 중앙화되고 버전이 관리되는 위키는 흩어져 있는 로컬 문서를 대체하여, 팀원 변동과 관계없이 프로젝트의 지식이 지속적으로 축적되고 활용될 수 있는 기반을 마련한다.

4.2 효율적인 회의 진행

OpenProject의 회의(Meetings) 모듈은 회의를 단순한 일정 항목이 아닌, 문서화되고 실행 가능한 프로젝트 활동으로 전환시킨다.16 이 모듈은 회의 준비, 진행, 후속 조치에 이르는 체계적인 워크플로우를 제공한다.

사용자는 일회성 회의 또는 반복 회의를 생성할 수 있다.17 회의 생성 시 제목, 시간, 장소 등 기본 정보를 입력하고, 가장 중요한 안건(Agenda)을 구성한다. 안건 항목은 텍스트로 작성할 수도 있고, 기존 작업 패키지를 직접 연결하여 논의의 맥락을 명확히 할 수도 있다.17

회의가 시작되면, 각 안건 항목 아래에 ’결과(Outcome)’를 기록할 수 있는 기능이 활성화된다. 이를 통해 회의 중에 내려진 결정이나 논의된 내용을 즉시 문서화할 수 있다.17 회의가 끝나면 참석자, 안건, 결과가 모두 포함된 회의록이 자동으로 생성되며, 이는 프로젝트의 영구적인 기록 자산이 된다.

참석자는 프로젝트 멤버 중에서 초대할 수 있으며, 초대된 참석자에게는 이메일로 알림이 발송된다.17 회의 일정은 iCalendar 형식으로 내보내 개인 캘린더와 동기화할 수 있다.17 이처럼 회의 모듈은 모든 논의와 결정 사항을 프로젝트 기록의 일부로 통합하여, 회의의 생산성을 높이고 후속 조치가 누락되지 않도록 보장한다.

5. 시간 추적 및 진행률 관리

마지막 장에서는 프로젝트 관리의 정량적인 측면, 즉 투입된 노력을 측정하고 작업의 완료도를 추적하는 방법에 대해 다룬다.

5.1 작업 시간 기록

OpenProject는 작업 패키지에 소요된 시간을 기록하고 추적하는 기능을 제공한다. 이는 프로젝트 비용을 산정하고, 팀의 작업 부하를 파악하며, 향후 계획의 정확도를 높이는 데 매우 중요하다.

시간을 기록하는 방법은 여러 가지가 있다 20:

1. 수동 기록: 작업 패키지 상세 보기에서 ‘Log time’ 기능을 선택하여 날짜, 소요 시간, 활동 유형(예: 개발, 기획), 그리고 상세 메모를 입력하는 방식이다.20

2. 실시간 타이머: 작업 패키지 내의 ‘Start time tracking’ 버튼을 눌러 실시간으로 시간을 측정하고, 작업이 끝나면 ‘Stop’ 버튼을 눌러 기록하는 방식이다. 이 방법은 실제 작업 시간을 정확하게 측정하는 데 유용하다.20

3. 커밋 메시지를 통한 기록: Git과 같은 버전 관리 시스템을 사용하는 개발자는 커밋 메시지에 특정 형식(refs #123 @2h)을 포함하여 시간을 자동으로 기록할 수 있다.20

기록된 시간은 권한에 따라 수정하거나 삭제할 수 있다.20 또한, 관리자는 특정 역할에 권한을 부여하여 다른 사용자를 대신해 시간을 기록하거나 편집하게 할 수 있다.20

5.2 작업 진행률 보고

작업 패키지의 진행률(%Complete)을 계산하고 보고하는 방식은 프로젝트의 특성과 관리 방법론에 따라 달라질 수 있다. OpenProject는 두 가지 상호 배타적인 진행률 추적 모드를 제공한다.21

이 두 모드의 선택은 단순한 사용자 선호도의 문제가 아니라, 프로젝트 관리 방법론의 근본적인 차이를 반영한다. 프로젝트 관리자는 프로젝트의 통제, 보고, 관리 부담 수준을 종합적으로 고려하여 가장 적합한 모드를 전략적으로 선택해야 한다.

1. 상태 기반(Status-based) 진행률:

이 모드에서는 진행률이 작업 패키지의 ’상태’에 따라 자동으로 결정된다. 예를 들어, 관리자는 ‘신규’ 상태를 0%, ‘진행 중’ 상태를 50%, ‘완료’ 상태를 100%로 미리 설정할 수 있다. 사용자가 작업 패키지의 상태를 변경하면 진행률도 자동으로 업데이트된다.21 이 방식은 상태의 흐름을 중시하는 애자일 및 칸반 방법론에 적합하며, 관리 부담이 적다는 장점이 있다.

2. 작업 기반(Work-based) 진행률:

이 모드에서는 진행률이 두 개의 수동 입력 필드, 즉 ’작업(Work, 총 예상 소요 시간)’과 ’남은 작업(Remaining work)’을 기반으로 계산된다. 계산 공식은 다음과 같다:

%Complete = Work(Work−Remaining work)​

예를 들어, 총 예상 소요 시간(‘Work’)이 50시간이고, 남은 작업 시간(‘Remaining work’)이 30시간이라면, 진행률은 (50−30)/50으로 계산되어 40%가 된다.21 이 방식은 정확한 공수 산정과 예산 대비 성과 측정이 중요한 전통적인 프로젝트 관리에 필수적이다. 하지만 각 작업에 대한 예상 시간을 산정하고 남은 시간을 꾸준히 업데이트해야 하므로 관리 부담이 더 크다.

두 모드는 프로젝트 설정에서 전환할 수 있으며, 전환 시 기존 데이터는 최대한 보존되거나 새로운 모드의 규칙에 따라 재계산된다.21

6. 작업 패키지

6.1 작업 패키지(Work Package)의 핵심 개념: 프로젝트의 원자(Atom)

OpenProject의 중심에는 ’작업 패키지(Work Package)’라는 핵심 개념이 자리 잡고 있다. 작업 패키지는 프로젝트 내에서 추적하고 관리해야 하는 모든 개별 항목(item)을 포괄하는 단위이다.7 이는 단순히 ’업무(Task)’나 ‘할 일(To-do)’ 목록을 의미하는 것을 넘어선다. 기능(Feature) 개발, 버그(Bug) 수정, 리스크(Risk) 관리, 사용자 스토리(User Story) 구현, 중요한 일정 지표인 마일스톤(Milestone), 프로젝트의 큰 단계를 나타내는 단계(Phase) 등 프로젝트를 구성하는 모든 요소를 작업 패키지로 표현할 수 있다.7

이러한 접근 방식은 의도된 아키텍처적 추상화의 결과물이다. 널리 사용되는 다른 도구인 Jira의 ’이슈(Issue)’가 본래 버그 추적 시스템에서 출발하여 점차 개념이 확장된 것과 달리, OpenProject의 ’작업 패키지’는 설계 초기부터 포괄적인 작업 단위를 염두에 두고 만들어졌다.9 이는 OpenProject가 특정 방법론이나 작업 유형에 얽매이지 않고자 하는 근본적인 설계 철학을 반영하는 것이다.3 이 구조적 유연성 덕분에, 사용자는 시스템이 강제하는 방식에 자신의 업무를 맞추는 것이 아니라, 조직의 독특하고 복잡한 프로세스를 시스템 안에서 자연스럽게 모델링할 수 있다.10 결과적으로 작업 패키지는 단순한 데이터 기록(record)이 아니라, 조직의 업무 흐름과 논리를 담아내는 유연한 컨테이너(container)로서 기능하게 된다.

6.2 Jira ’Issue’와의 비교: 관점의 차이

프로젝트 관리 도구 시장에서 Jira는 애자일 방법론과 이슈 트래킹 분야에서 강력한 영향력을 가진 독점 소프트웨어로 알려져 있다.9 OpenProject와 Jira는 이슈 추적, 백로그 관리, 보고서 생성 등 많은 기능적 유사점을 공유한다.9 하지만 두 도구는 근본적인 철학과 전략에서 뚜렷한 차이를 보인다.

가장 큰 차이점은 OpenProject가 오픈소스라는 점이다.9 소스 코드가 공개되어 있어 누구나 검토하고 수정할 수 있으며, 이를 통해 조직은 특정 벤더에 대한 종속성에서 벗어나 완전한 독립성과 자율성을 확보할 수 있다. 반면, Jira는 독점 소프트웨어로서 사용자는 코드에 접근할 수 없으며, 모든 업그레이드와 기능 개선은 전적으로 개발사인 Atlassian에 의존해야 한다.9

호스팅 전략 또한 중요한 차이점이다. Jira는 클라우드 버전에 집중하면서 온프레미스(On-premises) 서버 제품에 대한 지원을 점차 축소하고, 2024년 봄부터는 신규 판매를 중단했다.9 이는 사용자들이 데이터를 Atlassian이 관리하는 클라우드 인프라에 의존하도록 유도하는 전략이다. 반면, OpenProject는 클라우드 호스팅과 온프레미스 설치 옵션을 모두 동등하게 제공하여 사용자에게 선택권을 부여한다.9

이러한 호스팅 전략의 차이는 단순한 배포 옵션의 문제를 넘어, 데이터 거버넌스에 대한 철학의 차이를 명확하게 보여준다. Jira의 클라우드 중심 정책은 데이터가 AWS와 같은 특정 클라우드 벤더의 인프라에 저장되고 관리됨을 의미한다.9 반면, OpenProject의 온프레미스 옵션은 조직이 자체 서버에 시스템을 구축함으로써 데이터의 물리적 위치와 접근 통제권을 100% 소유할 수 있게 한다. 이는 곧 ’데이터 주권’의 확보를 의미하며, GDPR과 같이 엄격한 데이터 보호 규제를 준수해야 하는 유럽 지역의 기업이나, 데이터 보안이 최우선 과제인 금융, 국방, 의료 분야의 대기업에게는 단순한 선호의 문제가 아닌, 비즈니스를 위한 필수 요건이 된다.4 따라서 OpenProject의 작업 패키지는 단순한 업무 데이터가 아니라, 조직이 완벽하게 소유하고 통제할 수 있는 핵심 디지털 자산(asset)으로서의 가치를 지닌다.

7. 작업 패키지의 해부학: 구조와 속성

7.1 작업 패키지 유형(Types): 업무의 정체성 정의

작업 패키지 ’유형(Type)’은 해당 작업 패키지가 프로젝트 내에서 어떤 성격과 목적을 갖는지를 정의하는 가장 근본적인 분류 체계이다.7 이는 단순한 라벨링을 넘어, 작업 패키지의 행동 양식과 표시 방법을 결정하는 핵심적인 속성이다. OpenProject는 기본적으로 Task(업무), Feature(기능), Bug(버그), Phase(단계), Milestone(마일스톤) 등 일반적인 프로젝트 관리에서 널리 사용되는 유형들을 제공한다.7

• Task(작업): 프로젝트 목표 달성을 위해 수행해야 할 구체적인 활동.
• TaskGroup(작업 그룹): 작업 그룹의 집합.
• Feature(기능): 제품이나 서비스가 사용자에게 제공해야 할 새로운 기능적 요구사항.
• Bug(버그): 소프트웨어나 제품에서 발견된 결함이나 오류.
• Phase(단계): 프로젝트를 논리적인 구간으로 나눈 것으로, 시작일과 종료일을 가지는 기간을 나타낸다. 간트 차트에서 여러 Task를 포함하는 상위 바로 표시된다. (현재 버전 지원하지 않음)
• Milestone(마일스톤): 프로젝트의 중요한 중간 목표나 완료 시점을 나타내는 지표. 기간이 없는 특정 날짜를 가리키며, 간트 차트에서 다이아몬드 형태로 표시된다.13

시스템 관리자는 조직의 필요에 따라 이러한 기본 유형을 수정하거나, 완전히 새로운 유형을 생성할 수 있다. 이 설정은 Administration -> Work packages -> Types 메뉴에서 이루어지며, 각 유형의 이름, 간트 차트 표시 색상, 워크플로 복사 여부 등을 지정할 수 있다.13 유형 목록의 순서를 변경하여 새로운 작업 패키지를 생성할 때 기본으로 선택될 유형을 지정하는 것도 가능하다.14

7.1.1 애자일 유형 심층 분석

애자일 개발 방법론을 지원하기 위해 OpenProject는 Epic, User Story와 같은 특수한 유형을 활용한다. 이들은 단순한 분류를 넘어 애자일 프로세스의 핵심 구성 요소로 기능한다.

• Epic(에픽): 하나의 스프린트나 이터레이션 내에서 완료하기 어려운 큰 규모의 작업 단위를 의미한다. 보통 여러 개의 사용자 스토리로 분해된다.15
• User Story(사용자 스토리): 사용자 관점에서 원하는 기능이나 목표를 서술한 작은 단위의 요구사항이다. “사용자로서 [목표]를 할 수 있기를 원한다. 왜냐하면 [이유] 때문이다“와 같은 형식을 따른다.15

이러한 애자일 관련 유형들은 특히 ‘백로그(Backlogs)’ 모듈과 긴밀하게 연동된다. 관리자가 Administration -> Backlogs 설정에서 특정 유형(예: Epic, User Story, Bug)을 ’스토리 유형(Story types)’으로 지정하면, 해당 유형의 작업 패키지들은 제품 백로그에 나타나 우선순위 지정, 스토리 포인트 추정, 스프린트 계획 등의 활동에 사용된다.16

여기서 중요한 점은 작업 패키지 ’유형’이 단순한 분류 태그가 아니라, OpenProject 내 다른 모듈의 동작 방식을 결정하고 특정 워크플로를 활성화하는 ‘트리거(trigger)’ 역할을 한다는 것이다. 예를 들어, 어떤 작업 패키지의 유형을 ’Milestone’으로 설정하는 순간, 이 패키지는 간트 차트에서 일반적인 막대 바가 아닌 특정 시점을 나타내는 마름모꼴 아이콘으로 시각화된다.13 마찬가지로, 유형을 ’User Story’로 지정하면 백로그 모듈에서 스토리 포인트(Story points)를 입력하는 필드가 활성화되고, 이를 기반으로 스프린트의 번다운 차트(Burndown chart)가 자동으로 계산된다.17 따라서 관리자가 새로운 유형을 설계할 때는, 이 유형이 단순히 무엇을 의미하는지를 넘어, 간트 차트, 백로그, 애자일 보드 등 어떤 모듈과 상호작용하고, 어떤 상태 전환 규칙(워크플로)을 따르게 할 것인지를 종합적으로 고려해야 한다. 이는 OpenProject를 조직의 프로세스에 맞게 최적화하는 첫걸음이다.

7.2 작업패키지 유형 (개정)

Epic (에픽)

• 최상위 레벨의 거대한 작업 단위.
• 하나의 큰 목표나 매우 복잡한 기능을 의미하며, 여러 개의 Feature나 User Story로 구성됨.
• 예: “새로운 모바일 앱 출시”, “온라인 결제 시스템 구축”

Feature (기능)

• Epic을 구성하는 사용자에게 가치를 제공하는 구체적인 기능 묶음.
• Epic보다는 작지만, 여전히 여러 개의 User Story를 포함할 수 있는 규모.
• 예: Epic이 ’온라인 결제 시스템 구축’이라면, Feature는 “신용카드 결제 기능”, “계좌이체 기능”, “간편 결제 연동 기능” 등이 될 수 있음.

User Story (사용자 스토리)

• 사용자의 관점에서 원하는 기능이나 요구사항을 간단한 문장으로 기술.
• 애자일 개발의 핵심 요소로, “As a [사용자 유형], I want [목표/기능], so that [이유/가치]” 형식으로 작성되는 경우가 많음.
• 하나의 Feature를 구현하기 위해 여러 개의 User Story를 작성.
• 예: Feature가 ’신용카드 결제 기능’이라면, User Story는 “사용자로서, 결제 페이지에서 내 신용카드 정보를 저장하여 다음 결제 시 빠르게 사용할 수 있다“가 될 수 있음.

Task (과제)

• User Story를 완료하기 위해 개발팀이 수행해야 하는 가장 작은 실제 작업 단위.
• 기술적인 세부 작업들이 Task로 분할.
• 예: User Story를 위해 “결제 API 연동”, “카드 정보 암호화 모듈 개발”, “결제 UI 디자인” 등의 Task를 생성할 수 있음.

Bug (버그)

• 제품이나 소프트웨어의 오류, 결함, 예상과 다르게 동작하는 문제를 의미.
• 위의 계층 구조와는 별개로, 테스트나 사용자 피드백을 통해 발견되어 생성되는 작업 유형.

Milestone (마일스톤)

• 프로젝트의 주요 중간 목표 지점이나 중요한 이벤트를 나타내는 표시.
• 기간을 가지는 작업이라기보다는 ’특정 시점’을 의미하며, “베타 버전 출시”, “1차 개발 완료” 등과 같이 프로젝트의 진척도를 가늠하는 척도로 사용.

Summary Task (작업그룹)

• 여러 개의 하위 작업(Tasks)들을 그룹화하여 관리하기 위한 상위 작업입니다. OpenProject에서는 Phase(단계) 유형이 이와 유사한 역할.
• 요약 작업 자체는 직접 일을 수행하지 않으며, 하위 작업들의 진행 상황(진척도, 기간 등)을 요약하여 보여주는 컨테이너 역할.

일반적으로 다음과 같은 상하 관계를 형성.

Epic (최상위 목표)
└── Feature (주요 기능 1)
├── User Story (세부 요구사항 1-1)
│     ├── Task (실제 개발 작업 1)
│     └── Task (실제 개발 작업 2)
└── User Story (세부 요구사항 1-2)
└── Task (실제 개발 작업 3)
└── Feature (주요 기능 2)
└── User Story (세부 요구사항 2-1)
├── Task (실제 개발 작업 4)
└── Task (실제 개발 작업 5)

7.3 핵심 속성(Attributes) 분석: 작업의 DNA

모든 작업 패키지는 그 종류와 상관없이 공통적으로 가지는 핵심적인 내장 속성(built-in attributes)들을 통해 자신의 상태와 정보를 표현한다. 이 속성들은 작업의 DNA와 같아서, 해당 작업이 누구에게 할당되었고, 언제까지 완료되어야 하며, 현재 어떤 상태에 있는지를 명확하게 정의한다.7

주요 핵심 속성은 다음과 같다:

• ID: OpenProject 인스턴스 내의 모든 프로젝트를 통틀어 부여되는 고유한 정수 값이다. 한번 생성되면 절대 변경되지 않으며, 작업 패키지를 유일하게 식별하는 키(key) 역할을 한다.7
• Subject(제목): 작업 패키지의 내용을 간결하게 설명하는 제목이다.7
• Type(유형): 앞서 설명한 작업 패키지의 정체성을 나타낸다 (예: Task, Bug).7
• Status(상태): 작업의 현재 진행 상태를 나타낸다 (예: New, In Progress, Done, Closed). 상태는 워크플로 규칙에 따라 변경될 수 있으며, 프로젝트 현황을 파악하는 가장 중요한 지표 중 하나이다.18
• Assignee(담당자) / Accountable(책임자): 해당 작업을 직접 수행하는 담당자와 최종 책임이 있는 책임자를 지정한다. 특정 사용자뿐만 아니라 사용자 그룹 또는 역할 기반의 플레이스홀더(placeholder)에게도 할당할 수 있어 유연한 자원 관리가 가능하다.19
• Priority(우선순위): 다른 작업들과의 상대적인 중요도나 긴급성을 나타낸다 (예: Low, Normal, High, Immediate).7
• Start date(시작일) / Finish date(종료일): 작업이 시작될 예정일과 완료될 예정일을 명시한다. 이 날짜들은 간트 차트의 막대 길이와 위치를 결정한다.20
• Duration(기간): 시작일과 종료일 사이의 기간을 나타낸다. 시작일과 기간을 입력하면 종료일이 자동으로 계산되는 등 상호 연동된다.20
• Estimated time (Work)(예상 시간): 해당 작업을 완료하는 데 필요할 것으로 예상되는 총 작업 시간을 시간 단위로 기록한다. 부모-자식 관계에서는 자식들의 예상 시간이 합산되어 부모의 예상 시간으로 자동 계산되기도 한다.14
• Remaining time(잔여 시간): 남은 예상 작업 시간을 기록한다.20
• % Complete(진척도): 작업의 완료율을 백분율로 표시한다. 이 값은 ’상태’에 따라 자동으로 설정되게 하거나(예: ‘In Progress’ 상태는 50%), ‘예상 시간’ 대비 ’소요 시간’을 기반으로 수동 또는 자동으로 계산되도록 설정할 수 있다.14

이러한 속성들은 OpenProject API를 통해 외부 시스템과 연동할 때 더욱 명확한 기술적 사양을 갖는다. 예를 들어, API 문서에 따르면 ID는 Integer 타입이며 읽기 전용(READ-ONLY)이고, Subject는 String 타입으로 1에서 255자 사이의 길이를 가져야 하는 제약 조건이 있다.20 이처럼 각 속성은 명확한 데이터 타입과 규칙을 가지며, 이는 시스템의 데이터 정합성을 유지하는 기반이 된다.

7.4 정보 구조화 전략: 사용자 정의 필드와 카테고리

기본으로 제공되는 핵심 속성만으로는 모든 조직의 고유한 데이터 관리 요구사항을 충족시키기 어렵다. 이를 해결하기 위해 OpenProject는 ’사용자 정의 필드(Custom Fields)’와 ’카테고리(Categories)’라는 강력한 확장 기능을 제공한다.

7.4.1 사용자 정의 필드(Custom Fields)

사용자 정의 필드는 조직이 필요로 하는 어떠한 추가 정보라도 작업 패키지에 담을 수 있게 해주는 기능이다.21 예를 들어, ‘고객사명’, ‘영향받는 시스템’, ‘비용 코드’ 등 조직의 비즈니스 프로세스에 필수적인 정보를 위한 새로운 필드를 직접 만들 수 있다.

사용자 정의 필드는 Administration -> Custom fields 메뉴에서 생성하며, 매우 다양한 형식을 지원한다 21:

• Text, Integer, Float: 문자열, 정수, 실수 값을 입력받는다.
• List: 미리 정의된 목록에서 하나 또는 여러 개의 값을 선택하게 한다 (Multi-select).
• Date, Boolean: 날짜 선택기 또는 참/거짓(True/False) 체크박스를 제공한다.
• User, Version: 시스템에 등록된 사용자나 버전을 선택하게 한다.
• Hierarchy (Enterprise 기능): 다단계 계층 구조를 가진 목록을 만들 수 있다 (예: 대륙 > 국가 > 도시).

중요한 점은, 사용자 정의 필드를 생성했다고 해서 즉시 모든 작업 패키지에서 사용할 수 있는 것은 아니라는 점이다. 두 단계의 활성화 과정이 필요하다. 첫째, 생성된 필드를 특정 작업 패키지 유형의 입력 양식에 추가해야 한다 (Administration -> Work packages -> Types -> Form configuration).13 둘째, 해당 필드를 사용할 각 프로젝트의 설정에서 개별적으로 활성화해야 한다 (Project settings -> Work packages -> Custom fields).21 이 2단계 구조는 시스템 전반의 필드를 중앙에서 관리하면서도, 각 프로젝트의 특성에 맞게 필요한 필드만 선택적으로 사용할 수 있게 하는 유연성을 제공한다.

7.4.2 카테고리(Categories)

카테고리는 하나의 프로젝트 내에서 작업 패키지들을 추가적으로 분류하고 그룹화하기 위한 간편한 방법을 제공한다.23 사용자 정의 필드처럼 시스템 전역적으로 관리되는 것이 아니라, 각 프로젝트별로 독립적으로 설정된다 (Project settings -> Work packages -> Categories). 예를 들어, 개발 프로젝트에서는 ‘Frontend’, ‘Backend’, ’Database’와 같은 카테고리를, 마케팅 프로젝트에서는 ‘온라인 광고’, ‘콘텐츠 제작’, ’이벤트’와 같은 카테고리를 만들어 사용할 수 있다. 카테고리는 작업 패키지 테이블 뷰에서 필터링하거나 그룹화하는 기준으로 활용될 때 그 가치가 극대화된다. 또한, 특정 카테고리가 선택되었을 때 자동으로 특정 담당자가 지정되도록 설정할 수도 있어, 반복적인 할당 작업을 줄여준다.23

이러한 사용자 정의 필드와 카테고리는 단순히 정적인 데이터를 저장하는 필드를 넘어, 동적인 리포팅과 자동화의 핵심 기반이 된다. 예를 들어, ’고객사’라는 List 형식의 사용자 정의 필드를 생성하면, 이는 단순히 어떤 고객사와 관련된 작업인지를 기록하는 데 그치지 않는다. 작업 패키지 테이블 뷰에서 ’고객사별’로 작업을 그룹화하여 각 고객사별로 진행 중인 작업의 수와 총 예상 시간을 요약한 실시간 보고서를 즉석에서 만들어낼 수 있다.24 더 나아가, Enterprise 기능인 ’사용자 정의 액션(Custom Actions)’과 연계하면, “A 고객사의 Bug 유형 작업이 생성될 경우, 담당자를 ’고객 지원팀’으로 자동 할당하고 우선순위를 ’High’로 즉시 설정하라“와 같은 정교한 자동화 규칙을 구현할 수 있다.25 이처럼 잘 설계된 메타데이터(사용자 정의 필드와 카테고리)는 수동적인 데이터 관리를 예측 가능하고 자동화된 비즈니스 프로세스로 전환하는 강력한 열쇠가 된다.

8. 작업 패키지 생명주기 관리 (CRUD & Workflow)

8.1 생성(Create) 및 복제(Duplicate): 효율적인 작업 착수

OpenProject에서 작업 패키지를 생성하는 방법은 사용자의 상황과 목적에 따라 다양하게 제공되어 작업 착수의 효율성을 높인다.

• 테이블 뷰에서의 인라인(In-line) 생성: 작업 패키지 목록 하단의 + Create new work package 링크를 클릭하면, 마치 Excel 스프레드시트처럼 목록의 마지막 줄에 새로운 행이 추가된다. 여기서 바로 제목, 유형, 상태 등 주요 속성을 입력하고 Enter 키를 누르면 즉시 작업 패키지가 생성된다. 여러 개의 작업을 빠르게 목록화해야 할 때 매우 유용하다.26
• 분할 화면(Split Screen) 뷰에서의 상세 생성: 화면 우측 상단의 + Create 버튼을 클릭하고 생성할 유형을 선택하면, 왼쪽에는 기존 작업 목록이, 오른쪽에는 상세 정보 입력 양식이 있는 분할 화면이 나타난다. 이 방식은 제목, 설명, 담당자, 마감일 등 모든 속성을 처음부터 상세하게 입력하며 작업을 생성할 때 적합하다.8
• 전역(Global) 생성을 통한 빠른 접근: 페이지 상단 헤더의 + 아이콘을 클릭하면 현재 어떤 페이지에 있든지 상관없이 즉시 새로운 작업 패키지 생성 양식으로 이동할 수 있다. 이는 다른 모듈을 보다가 갑자기 새로운 작업을 등록해야 할 때 컨텍스트 전환 없이 빠르게 작업을 생성할 수 있게 해준다.8
• 컨텍스트 기반 생성: 간트 차트나 애자일 보드와 같은 특정 뷰 내에서도 직접 작업 패키지를 생성할 수 있다. 예를 들어, 간트 차트에서는 새로운 Task를 추가하여 타임라인에 바로 배치할 수 있고 27, 애자일 보드에서는 특정 상태(열)에 새로운 카드(작업 패키지)를 즉시 추가할 수 있다.28

복제(Duplicate) 기능은 반복적인 작업을 효율적으로 관리하기 위한 핵심 도구이다. 특정 작업 패키지를 복제하면, 원본의 제목, 설명, 유형, 우선순위 등 대부분의 속성 값이 그대로 복사된 새로운 생성 양식이 나타난다.29 사용자는 일부 정보만 수정하여 새로운 작업을 신속하게 생성할 수 있다. 이는 정기적으로 발생하는 유사한 버그 리포트, 테스트 케이스 생성, 표준화된 업무 요청 등에 매우 효과적이다.

8.2 조회(Read) 및 편집(Update): 정보 접근과 변경

생성된 작업 패키지의 정보를 조회하고 최신 상태로 유지하는 것은 프로젝트 관리의 기본이다. OpenProject는 이를 위해 직관적인 인터페이스와 강력한 편집 기능을 제공한다.

작업 패키지 정보는 주로 세 가지 뷰 모드를 통해 조회할 수 있다 30:

• 테이블 뷰(Table View): 모든 작업 패키지를 목록 형식으로 보여주며, 여러 작업의 상태를 한눈에 비교하고 분석하는 데 용이하다.
• 분할 화면 뷰(Split Screen View): 테이블 뷰에서 특정 작업 패키지를 클릭하면, 화면 오른쪽에 해당 작업의 상세 정보가 나타난다. 목록과 상세 내용을 동시에 보면서 작업 간의 컨텍스트를 빠르게 전환할 수 있다.
• 전체 화면 뷰(Full Screen View): 특정 작업 패키지를 더블 클릭하면, 해당 작업의 모든 상세 정보가 화면 전체에 표시된다. 설명, 댓글, 활동 기록 등 하나의 작업에 집중하여 검토하거나 편집할 때 유용하다.

작업 패키지의 속성을 편집하는 것은 매우 직관적이다. 상세 뷰(분할 또는 전체 화면)에서 수정하고자 하는 필드(예: 설명, 담당자, 마감일)를 클릭하면 바로 편집 모드로 전환되며, 변경 사항을 입력하고 저장하면 된다.8

**일괄 편집(Bulk Edit)**은 OpenProject의 생산성을 극대화하는 강력한 기능이다. 테이블 뷰에서 Ctrl 키를 누른 채 여러 작업 패키지를 선택한 후, 마우스 오른쪽 버튼을 클릭하여 컨텍스트 메뉴를 열면 선택된 모든 작업에 대해 상태, 담당자, 우선순위, 버전 등을 한 번에 변경할 수 있다.32 이 기능은 단순한 편의성을 넘어, 프로젝트 관리자가 변화에 신속하게 대응하는 핵심 전략 도구로 작용한다. 예를 들어, 프로젝트 계획이 변경되어 특정 마일스톤에 포함된 모든 작업의 마감일을 일주일씩 연기해야 하거나, 특정 팀원이 휴가를 가게 되어 그의 모든 미결 작업을 다른 팀원에게 재할당해야 하는 상황을 생각해보자. 수십, 수백 개의 작업 패키지를 하나씩 수정하는 것은 엄청난 시간을 소모할 뿐만 아니라 인적 오류를 유발할 가능성이 높다. 일괄 편집 기능을 사용하면, “X 스프린트에 할당된 모든 ‘Bug’ 유형 작업의 담당자를 Y에서 Z로 변경“과 같은 복잡하고 중요한 변경 작업을 단 몇 번의 클릭만으로 정확하고 신속하게 수행할 수 있다. 이는 프로젝트의 변화 대응 속도(agility)를 극적으로 향상시키고, 관리자가 반복적인 수작업에서 벗어나 더 전략적인 의사결정에 집중할 수 있도록 돕는다. 또한, 대규모 업데이트 시 관련자들에게 과도한 알림 이메일이 발송되는 것을 방지하기 위해, 일괄 편집 시 알림 전송을 비활성화하는 옵션도 제공된다.32

8.3 워크플로(Workflow) 설계: 프로세스의 규칙화

워크플로는 작업 패키지가 생성부터 완료까지 거치게 되는 생명주기를 정의하는 규칙의 집합이다. OpenProject에서 워크플로는 ’역할(Role)’과 ’유형(Type)’의 조합에 따라 허용되는 ‘상태(Status)’ 간의 전환을 제어하는 방식으로 구현된다.19 이는 조직의 고유한 업무 프로세스를 시스템에 내재화하여 일관성을 유지하고 오류를 방지하는 핵심적인 거버넌스 기능이다.

워크플로 설계는 Administration -> Work packages -> Workflow 메뉴에서 이루어진다. 설정 과정은 다음과 같다 33:

1. 컨텍스트 선택: 워크플로를 정의할 ’역할(예: Developer, Project Manager, QA)’과 ’작업 패키지 유형(예: Bug, Feature)’을 드롭다운 메뉴에서 선택한다.
2. 전환 규칙 설정: 화면에 상태 전환 매트릭스(matrix)가 표시된다. 행(row)은 현재 상태를, 열(column)은 전환될 수 있는 새로운 상태를 나타낸다. 특정 역할과 유형에 대해 허용할 상태 전환을 체크박스로 선택한다. 예를 들어, ‘Developer’ 역할이 ‘Bug’ 유형의 상태를 ’New’에서 ’In Progress’로 변경하는 것은 허용하지만, ’New’에서 ’Closed’로 바로 변경하는 것은 허용하지 않도록 설정할 수 있다.
3. 조건부 규칙 추가: 작업의 ’작성자(Author)’이거나 ’담당자(Assignee)’인 경우에만 특별히 허용되는 전환 규칙을 추가로 설정할 수 있다. 예를 들어, 일반 사용자는 댓글만 달 수 있지만, 담당자는 상태를 변경할 수 있도록 권한을 세분화할 수 있다.33

새로운 상태 값(예: ‘For Review’, ‘On Hold’)이 필요하다면 Administration -> Work packages -> Status 메뉴에서 먼저 생성해야 한다.18

이러한 워크플로 기능은 조직의 프로세스를 시스템에 강제함으로써 업무 품질을 통제하고, 잠재적인 병목 지점을 식별하는 강력한 거버넌스 도구로 기능한다. 예를 들어, 소프트웨어 개발 프로세스에서 ‘Bug’ 유형에 대해 다음과 같은 워크플로를 설계할 수 있다. ‘Developer’ 역할은 상태를 ‘New’ → ‘In Progress’ → ’Resolved’로만 전환할 수 있다. ‘QA’ 역할만이 ‘Resolved’ 상태의 버그를 검증하고 ‘Tested’ → ’Closed’로 전환하거나, 문제가 재발견되면 ‘Reopened’ 상태로 되돌릴 수 있다. 이러한 워크플로는 개발자가 충분한 테스트를 거치지 않고 임의로 버그를 종결시키는 것을 시스템적으로 방지한다. 이는 단순히 상태 변경을 관리하는 것을 넘어, 각 업무 단계의 담당자와 책임을 명확히 정의하고, 사전에 합의된 프로세스를 모든 구성원이 일관되게 따르도록 강제하여 최종 산출물의 품질을 보장하는 역할을 수행한다.

8.4 워크플로 자동화: 사용자 정의 액션(Custom Actions) (Enterprise 기능)

워크플로가 프로세스의 ’규칙’을 정의한다면, ’사용자 정의 액션(Custom Actions)’은 그 규칙의 실행을 ’자동화’하는 기능이다. 이는 Enterprise 에디션에서 제공되는 고급 기능으로, “단 한 번의 클릭으로 미리 정의된 여러 작업 패키지 속성을 동시에 변경하는 지능형 워크플로 자동화 버튼“이라고 할 수 있다.10

사용자 정의 액션은 Administration -> Work packages -> Custom actions 메뉴에서 설정하며, 두 가지 주요 요소로 구성된다 25:

• 조건(Conditions): 이 자동화 버튼이 어떤 상황에서 작업 패키지 화면에 나타날지를 정의한다. 예를 들어, “상태가 ’New’이고, 유형이 ’Feature’이며, 현재 사용자의 역할이 ’Project Manager’일 때“만 특정 버튼이 보이도록 설정할 수 있다.
• 동작(Actions): 사용자가 해당 버튼을 클릭했을 때 어떤 속성들이 어떻게 변경될지를 정의한다. 상태 변경뿐만 아니라 담당자, 우선순위, 마감일, 사용자 정의 필드 값 등 거의 모든 속성을 동시에 업데이트할 수 있다.

이 기능의 강력함은 실제 활용 사례를 통해 명확히 드러난다. 예를 들어, ‘신규 기능 아이디어 승인’ 프로세스를 자동화하는 시나리오를 생각해보자.10

1. 초기 상태: 아이디어가 ‘New’ 상태로 등록된다.
2. 승인 버튼: 프로젝트 관리자에게만 ’아이디어 승인(Approve Idea)’이라는 사용자 정의 액션 버튼이 보인다.
3. 자동화된 동작: 관리자가 이 버튼을 클릭하면, 시스템은 다음과 같은 동작을 한 번에 수행한다.

• 상태를 ’New’에서 ’Approved’로 변경한다.
• 담당자를 아이디어 제안자에서 ’개발팀 리더’로 변경한다.
• 우선순위를 ’Normal’로 설정한다.
• 시작일을 오늘 날짜로, 마감일을 2주 후로 자동 설정한다.
• 관련자들에게 변경 사항에 대한 알림을 보낸다.

이처럼 사용자 정의 액션은 기존의 워크플로를 ’수동적 규칙’에서 ’능동적 자동화’의 차원으로 격상시킨다. 일반적인 워크플로에서는 사용자가 상태를 ’Approved’로 변경한 뒤, 담당자를 찾아 할당하고, 우선순위를 설정하는 등 여러 단계를 수동으로 거쳐야 한다. 이 과정은 번거로울 뿐만 아니라, 일부 단계를 누락하는 인적 오류(human error)를 유발할 수 있다. 사용자 정의 액션은 이 모든 과정을 하나의 원자적 트랜잭션(atomic transaction)으로 묶어버린다. 이를 통해 조직은 프로세스의 표준화를 완벽하게 강제할 수 있으며, 담당자의 인지 부하를 크게 줄여주고, 데이터의 정합성과 일관성을 보장하여 전체적인 업무 처리 속도와 품질을 극대화할 수 있다.

9. 작업 패키지 관계망 구성: 계층과 의존성

9.1 수직적 관계: 계층 구조(Hierarchies)와 WBS

OpenProject는 작업 패키지 간의 부모-자식(parent-child) 관계 설정을 통해 수직적인 계층 구조를 구성할 수 있는 강력한 기능을 제공한다.34 이 기능은 복잡한 프로젝트나 대규모 작업을 관리 가능한 작은 단위로 체계적으로 분해하는 작업 분할 구조(Work Breakdown Structure, WBS)를 구현하는 데 필수적이다.

자식 작업 패키지를 추가하는 방법은 여러 가지가 있다 34:

• ‘Relations’ 탭 활용: 부모가 될 작업 패키지의 상세 뷰에서 ‘Relations’ 탭으로 이동한 후, + Relation 버튼을 클릭하여 ‘Create new child’(새로운 자식 생성) 또는 ‘Add existing child’(기존 작업 패키지를 자식으로 추가)를 선택한다.
• 테이블 뷰에서의 컨텍스트 메뉴 활용: 테이블 뷰에서 자식이 될 작업 패키지를 선택하고 마우스 오른쪽 버튼을 클릭한 후, ‘Indent hierarchy’(계층 들여쓰기)를 선택하면 바로 위에 있는 작업 패키지의 자식으로 편입된다.

일단 계층 구조가 설정되면, 이는 단순한 시각적 그룹화를 넘어서는 중요한 기능적 의미를 갖게 된다. 부모 작업 패키지의 주요 속성들, 특히 진척도(% Complete), 예상 시간(Work), 잔여 시간(Remaining work) 등은 더 이상 독립적인 값이 아니라, 그 아래에 있는 모든 자식 작업 패키지들의 값을 집계하여 자동으로 계산되는 종속적인 값이 된다.14

이 자동 집계 메커니즘은 상향식(Bottom-up) 비용 및 진척도 관리를 자동화하는 핵심적인 역할을 한다. 프로젝트 관리자는 프로젝트의 가장 세분화된 최하위 레벨의 작업(자식 패키지)에 대해서만 예상 시간을 입력하면 된다. 그러면 OpenProject는 이 값들을 자동으로 합산하여 상위 단계(부모 패키지) 및 프로젝트 전체의 총 예상 시간을 실시간으로 계산해준다.14 프로젝트가 진행됨에 따라, 각 팀원이 자신의 담당 작업(자식 패키지)의 진척도를 업데이트하면, 부모 작업 패키지의 진척도 역시 각 자식 작업의 예상 시간을 가중치로 한 평균값으로 자동 업데이트된다. 이는 관리자가 개별 작업의 세세한 진행 상황을 일일이 추적하는 마이크로매니징의 부담에서 벗어나, 프로젝트 전체의 현황과 리스크를 거시적인 관점에서 정확하고 시의적절하게 파악할 수 있도록 돕는 매우 강력한 기능이다.

9.2 수평적 관계: 의존성(Relations) 관리

프로젝트 내의 작업들은 단순히 상하 관계만으로 이루어지지 않는다. 어떤 작업은 다른 작업이 끝나야만 시작할 수 있거나, 특정 작업의 완료가 다른 작업의 상태에 영향을 미치는 등 복잡한 수평적 관계를 맺고 있다. OpenProject는 이러한 기능적, 시간적 의존성을 모델링하기 위해 다양한 ‘관계(Relations)’ 유형을 제공한다.34

관계 설정은 작업 패키지의 ‘Relations’ 탭에서 이루어지며, 사용자는 상황에 맞는 최적의 관계 유형을 선택해야 한다. 각 관계 유형은 고유한 의미와 시스템적 효과를 가지므로, 그 차이를 명확히 이해하는 것이 중요하다.

이처럼 다양한 관계 유형을 적절히 활용하면 프로젝트의 복잡한 내부 의존성 네트워크를 명확하게 시각화하고 관리할 수 있다. 특히 ‘선행/후행’ 관계와 ‘차단’ 관계는 비슷해 보이지만 그 효과가 근본적으로 다르다는 점을 이해하는 것이 중요하다. ‘선행/후행’ 관계는 작업의 ’일정(schedule)’에 직접적인 영향을 미치며 간트 차트에서 자동으로 일정을 조정하는 역할을 한다.35 반면, ‘차단’ 관계는 작업의 ‘상태(status)’ 변경을 제한하여, 정의된 프로세스 순서를 강제하는 역할을 한다.34 이러한 미묘하지만 중요한 차이를 이해하고 올바른 관계를 설정하는 것은 프로젝트의 리스크를 사전에 식별하고, 병목 현상을 방지하며, 전체적인 작업 흐름을 원활하게 유지하는 데 결정적인 역할을 한다.

10. 작업 패키지 시각화 및 분석

OpenProject는 동일한 작업 패키지 데이터를 다양한 관점에서 조망할 수 있도록 여러 가지 시각화 뷰(View)를 제공한다. 각 뷰는 고유한 목적과 장점을 가지며, 프로젝트 관리자와 팀원은 상황에 따라 최적의 뷰를 선택하여 데이터를 분석하고 의사결정을 내릴 수 있다.

10.1 테이블 뷰(Table View): 데이터 기반 분석의 중심

테이블 뷰는 모든 작업 패키지를 행(row)으로, 각 속성을 열(column)으로 표시하는 가장 기본적이면서도 강력한 데이터 분석 도구이다.30 단순한 목록 표시 기능을 넘어, 사용자가 원하는 형태로 데이터를 가공하고 분석할 수 있는 다채로운 설정 기능을 제공한다.24

• 열(Columns) 구성: 열 설정 메뉴를 통해 보고서에 필요한 속성(기본 및 사용자 정의 필드 포함)만 선택하여 표시하고, 드래그 앤 드롭으로 순서를 자유롭게 변경할 수 있다.
• 필터(Filters): 하나 이상의 조건을 조합하여 원하는 데이터만 정확하게 추출할 수 있다. 예를 들어, “담당자가 ’나’이고, 상태가 ‘Open’ 또는 ’In Progress’이며, 마감일이 ’이번 주’인 모든 ‘Bug’ 유형 작업“과 같은 복잡한 쿼리를 GUI를 통해 손쉽게 생성할 수 있다.
• 그룹화(Group by): 특정 속성을 기준으로 작업들을 그룹화하여 표시할 수 있다. ’담당자’를 기준으로 그룹화하면 각 팀원이 어떤 작업을 얼마나 맡고 있는지 명확하게 파악할 수 있고, ’상태’를 기준으로 그룹화하면 프로젝트의 전체적인 병목 현황을 한눈에 볼 수 있다.
• 정렬(Sort): 우선순위, 마감일 등 여러 속성을 기준으로 다중 정렬을 적용하여 데이터를 원하는 순서로 나열할 수 있다.
• 합계 표시(Display sums): Work(예상 시간), Remaining work(잔여 시간), % Complete(진척도)와 같은 숫자 형식의 속성에 대해 그룹별 소계 및 전체 총계를 자동으로 계산하여 표시해준다.

이러한 기능들을 조합하면, 테이블 뷰는 단순한 데이터 목록이 아니라, 사용자가 직접 만드는 ’커스텀 리포팅 엔진’으로 변모한다. 관리자는 별도의 비즈니스 인텔리전스(BI) 도구나 복잡한 엑셀 작업 없이도 “팀원별 주간 미처리 작업의 총 예상 시간”, “우선순위별 버그 분포 현황 및 해결률”, “고객사별 프로젝트 진행률” 등 다양한 관점의 심층적인 보고서를 즉석에서 생성할 수 있다. 이렇게 정교하게 구성된 뷰는 개인화된 ’저장된 뷰(Saved View)’로 저장하여 언제든지 다시 불러오거나, ’공개 뷰(Public View)’로 설정하여 다른 팀원들과 공유할 수 있다.24 이는 데이터에 기반한 신속하고 정확한 의사결정을 조직 문화로 정착시키는 데 핵심적인 역할을 한다.

10.2 간트 차트(Gantt Chart): 시간축 기반의 프로젝트 계획

간트 차트는 프로젝트의 모든 작업 패키지를 수평적인 타임라인 위에 막대 형태로 시각화하여, 프로젝트 전체의 일정과 작업 간의 선후 관계를 조망하는 데 최적화된 뷰이다.27

간트 차트의 주요 기능은 다음과 같다:

• 직관적인 일정 조정: 타임라인 위의 막대 바를 마우스로 드래그 앤 드롭하여 작업의 시작일과 종료일을 손쉽게 변경할 수 있다. 막대의 양 끝을 조절하여 기간을 늘리거나 줄이는 것도 가능하다.27
• 의존성 시각화 및 자동 조정: 작업 간의 ‘선행/후행(Precedes/Follows)’ 관계가 화살표 선으로 명확하게 표시된다. 여기서 핵심은, 선행 작업의 일정이 변경(예: 지연)되면, 그에 의존하는 모든 후행 작업들의 일정이 자동으로 연쇄 조정된다는 점이다.27
• 계층 구조(WBS) 표시: 부모-자식 관계가 들여쓰기 형태로 시각화되어, 프로젝트의 전체적인 구조를 파악하기 용이하다.35
• 기준선(Baseline) 비교 (Enterprise 기능): 프로젝트 계획 수립 시점의 초기 계획(기준선)을 스냅샷으로 저장한 후, 실제 진행 상황을 나타내는 현재의 간트 차트와 겹쳐서 표시할 수 있다. 이를 통해 계획 대비 실적의 차이(지연 또는 단축)를 시각적으로 명확하게 확인할 수 있다.9

OpenProject의 간트 차트는 단순히 완성된 계획을 보여주는 정적인 그림이 아니다. 이는 프로젝트 계획을 수립하고, 다양한 시나리오를 시뮬레이션하며, 변화에 대응하여 계획을 동적으로 조정하는 ’상호작용적인 계획 도구’이다. 예를 들어, 프로젝트 관리자는 간트 차트 상에서 특정 핵심 작업의 기간을 임의로 며칠 늘려보는 것만으로도, 그 작업에 의존성을 가진 모든 후속 작업들의 일정이 연쇄적으로 어떻게 밀리는지, 그리고 최종 프로젝트 완료일에 어떤 영향을 미치는지 즉시 시각적으로 확인할 수 있다. 이러한 시뮬레이션 기능은 잠재적인 병목 현상이나 리스크를 사전에 식별하고, “특정 작업에 리소스를 추가 투입하여 기간을 단축했을 때의 효과“나 “작업 순서를 변경했을 때의 전체 일정 변화” 등 여러 대안의 결과를 비교 분석하여 최적의 프로젝트 계획을 수립하는 데 결정적인 도움을 준다.

10.3 애자일 보드(Agile Boards): 워크플로 중심의 협업

애자일 보드는 칸반(Kanban) 또는 스크럼(Scrum)과 같은 애자일 방법론을 적용하여 팀의 작업 흐름을 시각적으로 관리하기 위한 도구이다.15 보드는 일반적으로 ‘To Do’, ‘In Progress’, ’Done’과 같이 작업의 상태를 나타내는 여러 개의 수직적인 리스트(열)와, 각 리스트 안에 위치하는 개별 작업 패키지를 나타내는 카드(card)로 구성된다.

OpenProject는 두 가지 종류의 애자일 보드를 제공한다:

• Basic Board (Community Edition): 사용자가 원하는 이름으로 자유롭게 리스트를 생성하고, 카드를 리스트 간에 자유롭게 이동시킬 수 있다. 이 보드의 가장 큰 특징은 카드를 다른 리스트로 옮겨도 해당 작업 패키지의 속성(예: 상태)이 자동으로 변경되지 않는다는 점이다. 이는 아이디어 수집, 브레인스토밍 결과 정리 등 정형화된 워크플로가 필요 없는 자유로운 형태의 목록 관리에 적합하다.28
• Action Board (Enterprise Edition): 이 보드의 각 리스트는 작업 패키지의 특정 속성 값과 직접적으로 매핑된다. 예를 들어, ’Status Action Board’의 ‘New’, ‘In Progress’, ‘Done’ 리스트는 각각 작업 패키지의 ‘New’, ‘In Progress’, ‘Done’ 상태에 해당한다. 사용자가 카드를 ‘In Progress’ 리스트에서 ‘Done’ 리스트로 드래그 앤 드롭하면, 시스템은 이 행위를 해당 작업 패키지의 상태를 ’Done’으로 변경하는 명령으로 인식하고 속성을 자동으로 업데이트한다. 이는 팀의 작업 흐름을 표준화하고 상태 업데이트를 자동화하는 데 필수적인 기능이다.28 Action Board는 상태(Status) 외에도 담당자(Assignee), 버전(Version), 상위 작업(Parent) 등 다양한 속성을 기준으로 생성할 수 있다.

Action Board는 팀의 작업 흐름을 실시간으로 시각화하고, 사전에 정의된 프로세스 규칙을 강제하며, 상태 업데이트와 같은 반복적인 작업을 자동화하는 ‘살아있는 워크플로’ 그 자체이다. 개발자가 ‘In Progress’ 리스트에 있는 카드를 ‘For Review’ 리스트로 옮기는 행위는 단순히 보드 위의 시각적 위치를 바꾸는 것이 아니다. 시스템의 관점에서 이는 ’해당 작업 패키지의 상태를 In Progress에서 For Review로 변경’하는 명확한 트랜잭션이다. 이와 연동하여, 담당자를 자동으로 QA 리더에게 재할당하고, 관련자들에게 리뷰 요청 알림을 보내는 등의 후속 조치를 자동화할 수 있다. 이는 팀원들이 복잡한 상태 변경 절차나 규칙을 일일이 기억할 필요 없이, 보드 위에서 카드를 옮기는 직관적인 행위만으로도 조직이 정의한 프로세스를 정확하게 따르도록 유도한다. 이를 통해 병목 현상을 쉽게 식별하고, 작업의 흐름을 최적화하며, 팀 전체의 협업 효율성을 극대화할 수 있다.